home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / tcp90114.zip / TCP90114.TXT < prev   
Text File  |  1990-09-20  |  5KB  |  135 lines
  1. TCP-Group Digest            Mon, 20 Aug 90       Volume 90 : Issue 114
  2.  
  3. Today's Topics:
  4.                       ARPing through digipeaters
  5.                        NOS NET/ROM code broken
  6.                         Old bug still present
  7.                      Request for RIP Info/Thanks
  8.  
  9. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>
  10. Send requests of an administrative nature (addition to, deletion from the
  11. distribution list, et al) to: <ListServ@UCSD.Edu>
  12.  
  13. Archives of past issues of the TCP-Group Digest are available
  14. (by FTP only) from UCSD.Edu in directory "mailarchives".
  15. ----------------------------------------------------------------------
  16.  
  17. Date: Sun, 19 Aug 90 23:54:09 CDT
  18. From: Jay Maynard <jmaynard@thesis1.hsch.utexas.edu>
  19. Subject: ARPing through digipeaters
  20. To: tcp-group@ucsd.edu
  21.  
  22. We discovered that ARP requests aren't replied to unless the packet has been
  23. through all the digipeaters in the AX25 path for QST. This is probably a
  24. feature, but it limits the usefulness of ARP to the area served by one local
  25. digipeater. Since we can't afford to dedicate a stack of PCs, or Kantronics
  26. Data Engines, or whatever, to do it right, we're stuck with using digipeaters
  27. to get from point A to point B. Can anyone suggest a way to cover a large
  28. metropolitan area using basic equipment? Purist flames to /dev/null, please.
  29.  
  30. ------------------------------
  31.  
  32. Date: Sun, 19 Aug 90 15:03 GMT
  33. From: <DEVANS%COLOLASP.BITNET@CORNELLC.cit.cornell.edu>
  34. Subject: NOS NET/ROM code broken
  35. To: tcp-group@ucsd.edu
  36.  
  37. That error message is exactly the one that I am getting (except that
  38. I get a LOT more than just one) when I compile 900730 with TC++. I
  39. think you will find that it has no effect on the operation of NOS
  40. itself. Neither is it restricted to the NETROM code. Depending on
  41. what you put ion your autoexec file, you can get the error message
  42. (which comes from 'free') to point to any one of a number of
  43. routines.
  44.  
  45. 73 -- Doc
  46.  
  47. ------------------------------
  48.  
  49. Date: Sun, 19 Aug 90 14:52 GMT
  50. From: <DEVANS%COLOLASP.BITNET@CORNELLC.cit.cornell.edu>
  51. Subject: Old bug still present
  52. To: tcp-group@ucsd.edu
  53.  
  54. Several months ago, I posted details of a NOS bug which caused system
  55. crashes. Since NOS became much more stable around June time, I didn't
  56. think to test for the bug, assuming that it had gone away. Six crashes
  57. in the space of half an hour yesterday convinced me otherwise!
  58.  
  59. I was running plain vanilla NOS 900730 with executable downloaded
  60. from thumper.
  61.  
  62. The problem appears to arise when a station connects to NOS using
  63. pure NETROM at the same time that there is already a TCP/IP
  64. connection between the two stations. The symptoms are that the
  65. entire system halts: screen output stops and the keyboard is
  66. locked. A reset appears to be all that can be done.
  67.  
  68. To self-inflict the crash, perform the following:
  69. (you mat want to do this with tracing on)
  70. 1. telnet to yourself;
  71. 2. Issue the N command;
  72. 3. Connect to a nearby NETROM node;
  73. 4. When that completes, Connect back to yourself
  74. Shortly after that connection completes, and after the mailbox
  75. login message has left your system, the system should completely
  76. lock up.
  77.  
  78. Just to be clear, this is the sequence that I go through:
  79. telnet nq0i
  80. (login sequence)
  81. N
  82. (Connected to 1400004:NQ0I msg and msg about the escape character)
  83. C FNL [FNL is Ft. Collins NETROM node]
  84. (Connect msg)
  85. C NQ0I
  86. (Connect message)
  87. Shortly afterwards, the system stops.
  88.  
  89. The problem arose yesterday when a local station also running 900730
  90. made a pure NETROM connection to me at the same time that I was
  91. sending him TCP/IP traffic; it proved to be impossible to keep
  92. the system up under these circumstances.
  93.  
  94.   Doc  nq0i
  95.  
  96. SPAN:   ORION::DEVANS
  97. BITNET: devans@cololasp
  98. Internet: devans@orion.colorado.edu
  99. Snail:  Radiophysics, Inc., 5475 Western Ave., Boulder, Colorado 80301 USA
  100. Analogue switching network: (303)-447-9524
  101.  
  102. Non-work-related may also go to:
  103. Packet (AX.25): NQ0I @ KE0XA
  104. Packet (TCP/IP): nq0i@nq0i.ampr.org [44.20.0.3]
  105.  
  106.  
  107.                               ..._._
  108.  
  109. ------------------------------
  110.  
  111. Date: Sun, 19 Aug 90 22:12:55 EDT
  112. From: "Jim Campbell" <jimc@ralvm11.iinus1.ibm.com>
  113. Subject: Request for RIP Info/Thanks
  114. To: tcp-group@ucsd.edu
  115.  
  116. I have been able to figure out how to use Telnet, FTP, etc., based on the
  117. available documentation.  However, I can't figure out what RIP is all
  118. about.  Can some kind soul provide a brief tutorial on what it does, and
  119. how to use such commands as RIP MERGE, RIP ADD, RIP REQUEST, etc?
  120.  
  121. Also, my thanks to Bill@ke8kb and Paul@ei9gl for their kind help in getting
  122. my DRSI board working with NOS.  Since I have only SMTP access to the
  123. internet, David Singer retrieved the latest NOS source for me (thanks David),
  124. and I compiled it.  After some learning experiences, all is working OK.
  125. I'm now looking forward to trying out some of the more exotic features.
  126.  
  127. Jim Campbell
  128. Research Triangle Park, N.C.      (Internet:  jimc@ralvm11.iinus1.ibm.com)
  129.                                    (AMPRNET:  w4bqp.ampr.org)
  130.  
  131. ------------------------------
  132.  
  133. End of TCP-Group Digest
  134. ******************************
  135.